Medical Image Capture System and Method

ABSTRACT

As patient video images are captured in a lab, they are converted into an uncompressed data set and stored locally on a hospital site server, where they are immediately viewable by diagnosticians in the hospital. The hospital site server generates a plurality of compressed data sets for use by the Internet Data Center. Additionally, the uncompressed data set and a plurality of compressed data sets are stored permanently on a centralized Internet Data Center, from which they can be searched out and displayed by any client device running web-browser software. A client is provided with immediate access to the uncompressed images when pausing and requesting the images of interest from the server. The patient video images are automatically delivered to any authorized Clinical Research Organizations, they are delivered back to the treating hospital when the patient returns for subsequent visits, and are viewable through in-hospital viewing stations over a private high-speed network.

RELATED APPLICATIONS

This application is a Continuation of U.S. application Ser. No.09/974,406, filed on Oct. 9, 2001, which claims the benefit under 35U.S.C. 119(e) of U.S. Provisional Application No. 60/240,681, filed onOct. 16, 2000, both of which are incorporated herein by reference intheir entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates to systems and methods for collecting medicalvideo images of a patient and delivering the video images to a remotestation. More specifically, the invention is directed to a system andmethod for transferring cardiac video images with negligible imagedegradation, archiving the images in long-term storage media, andproviding a streaming multi-media video file that allows medicaldiagnosis and collaboration by doctors located outside the immediatetreating hospital.

2. Description of the Related Art

Current advances in technologies related to compression, storage, andretrieval of digital video data are making their way into the medicalfield. These advances are making digital storage and display aneconomical means for hospitals and doctors to archive and review patientrecords. The scope of economic feasibility extends to cost, time, andimage quality.

Traditional methods of archiving patient records involve substantialcosts incurred from the physical media and allocating shelf space tostore the same. Traditional paper and film storage methods require asignificant amount of space, oftentimes requiring an entire filing roomto store the accumulation of data. Newer digital methods of storingpatient information require a system of removable high-capacity storagedevices, such as tape drives, magneto-optical disk drives and recordablecompact disks, which require a significant amount of cost and time tofile and retrieve.

The time required to file and retrieve physical media in a storagefacility is cumbersome, as a filing clerk is required to understand thefiling structure, find the correct digitally recorded media, and thendeliver the media to the diagnostician requesting the record.

Currently, archiving of patient video images is often performed withanalog means, such as 35 mm black and white cine′ film. Archiving andretrieving of such films are expensive and cumbersome. First of all,there is a significant cost associated with the chemicals required todevelop the film. These chemicals must be kept at a specific temperatureand they break down over a short period of time. The chemicals must bereplaced frequently or there is a risk of compromising the quality ofthe medical image. This results in a higher cost for facilities with lowvolume. Secondly, this requires the creation and maintenance of astorage facility at optimum atmospheric conditions to preserve the film.Thirdly, the space required to store large numbers of film canisterstakes up a significant amount of space. Hospitals would prefer to usethis space for revenue generating purposes, such as patient rooms orlabs. Finally, the process of reviewing a linear film to find aparticular physiological event is time consuming.

In addition to cine′ film, another method of recording analog video datais to incorporate a professional grade videotape recorder into the imageacquisition system. A serious disadvantage of this method, like thecine′ film, is the tedious searching along the linear videotape to finda specific physiological event a diagnostician wishes to view. Playbackrequires special commercial grade videotape players. These are expensiveand are not typically available in each of the many locations in abuilding where a physician may wish to review the image data. Thisforces the physician to seek out the player. In a situation where thephysician needs to consult the images before treating the patient, it isalways possible he or she will be interrupted on the way back to thepatient, thus affecting his or her retention of the image. Anotherinherent disadvantage is the physical size of the videotape and thestorage area necessary to harbor large quantities of patientinformation. Still another disadvantage is the fact that any relevantpatient demographic information is only available visually and does notallow electronic databasing for quick retrieval. Thus, videotape is notan ideal solution to storage and retrieval of medical video images.

Many medical personnel have desired a digital means of archiving,searching, retrieving and viewing patient video data. There are currentdigital systems that allow digital video data to be recorded ontransportable media such as magneto-optical or recordable opticalcompact discs. These systems provide transportable media with theability to efficiently store large amounts of video data and methods forviewing the video images through a display device, such as a videomonitor. However, there are still considerable drawbacks in currentdigital archiving systems.

An inherent problem associated with digital storage of medical videodata is the file size that can be many megabytes per procedure. Files ofthese sizes can require a large amount of bandwidth, storage space, andmemory. Thus, compression techniques become imperative when dealing withdigitized video data. Image compression is usually accomplished in oneof two ways. First is the intra-frame technique, wherein the compressiontakes place within each individual frame. Color depth may be reduced,image size altered, or resolution decreased to achieve an acceptablefile size. An alternative method is the inter-frame compressiontechnique, wherein compression is accomplished between frames. Multipleframes that do not significantly change from one to the next may becollapsed into a single frame that is then displayed during the timenormally reserved for previous collection of frames.

In dealing with medical images, image quality is normally more importantthan file size. Unlike other types of multi-media applications, medicalapplications require detailed images since those images are often thebasis for medical diagnoses. The original image quality is often termedlossless, denoting that there is no loss between the original image andthe digitized version. Images that have undergone compression arelabeled lossy images, denoting that some image quality has been lost dueto compression. Many current compression techniques can slightlycompress images with negligible image degradation. Unfortunately, theinherent sacrifice with compression is that as compression ratios areincreased, image quality is decreased. Therefore, it is imperative thatany compression results in negligible image degradation, and that thelossless images are immediately available for viewing.

Several systems have been implemented for compressing medical videoimages and then archiving them to digital media. One such system isdisclosed in Lobodzinski, U.S. Pat. No. 5,619,995, which discloses asystem for combining diagnostic digital motion video acquisition,display, and processing with physiological data indexing throughutilization of techniques of digital motion video compression throughdomain transformation.

While some of the prior art systems allow for video storage, many ofthese systems require the doctor to have access to, or a copy of, theremovable storage media. This is inefficient because without additionalcopies, only one physician can view the video data at a time, andviewing the data from a remote location requires video data media to bemailed or transmitted electronically such as through e-mail. This is atime consuming process that requires a large amount of storage space dueto the large image file sizes. Moreover, either method of deliveringvideo data to a remote location is critically deficient when a doctormust immediately diagnose a patient condition and does not possess thestorage media or have the data saved locally on a computer.

Additionally, it may be desirous that organizations other than thehospital have access to patient video data. One such organization is aclinical research organization. Unfortunately, it is tedious and costlyto make copies of digital video media and mail them to the variousorganizations requiring the patient video data.

What is needed is a system that provides physicians with a convenientway to view patient video data from remote locations. Additionally, itis desirous for a system to allow sharing of a single video data filefrom multiple locations simultaneously. Furthermore, a storage mediathat does not require a substantial amount of space or retrieval timewould greatly enhance the benefits of digital archiving.

SUMMARY OF THE INVENTION

Embodiments of the invention relate to a system that captures, storesand transmits video images such as those taken during a cardiaccatheterization procedure. As video data are captured through a videoinput device, such as an X-Ray Angioplasty Machine, it is combined withpatient demographic information, such as patient name and ID, in anacquisition station. The acquisition station captures and stores thevideo data in a format such as a Digital Imaging and Communications inMedicine (DICOM) data set. Each data set typically corresponds toseveral runs of a particular catheterization procedure. Thus, one “set”provides several related video images.

The acquisition station converts any analog images from the video camerainto digital data. The acquisition station then sends the resultingDICOM data set through a high speed data network to a site servercomputer that may be located at or near the acquisition station, such aswithin the same hospital. This process is performed automatically andalmost instantaneously following input of the patient demographicinformation and capturing of the patient video data from a proceduresuch as cardiac angioplasty. Thus, patient video data becomesimmediately accessible by other practitioners having data links to thesite server.

The site server temporarily stores the “lossless” DICOM data set locallyand allows practitioner's in the hospital to view the DICOM data setsthrough in-hospital review stations that are connected to the privatehigh speed network. The DICOM images are termed “lossless” because nocompression is used to store these files.

Once the site server receives the DICOM data sets from a series ofpatient procedures, a “thumbnail” image representing each patientprocedure is generated and stored along with the DICOM data set.Advantageously, the thumbnail image is preferably taken from a centerframe of a video procedure. Because the die or contrast media usedduring, for example, a cardiac catheterization procedure is not asapparent in either the beginning or ending frames, taking a thumbnailimage from the center frame is more likely to be an accuraterepresentative image of the procedure.

After a thumbnail image has been created, instructions within the siteserver generate different compressed video files from the DICOM file.Each procedure video is preferably used to generate three separate videofiles that are compatible with a computer video display program, such asthe QUICKTIME player from Apple Computer, Inc. The three video files arepreferably generated with differing amounts of compression so that theycan be played to end users across various bandwidth links. For example,an end user with a low bandwidth connection to the site server wouldwant to view a highly compressed file, even through some loss of videoquality will result from the high compression. However, an end user witha high bandwidth connection would want to view a procedure video that isonly slightly compressed so that they can receive the highest videoquality.

Once the compressed video files have been generated they areautomatically sent using a secured encrypted virtual private network(VPN) connection to a server within a central Internet data center(IDC). In addition, the DICOM data sets are also sent at the same time,or a later time, to the IDC. Advantageously, the DICOM data sets aresent when bandwidth requirements on the IDC are detected to be low, suchas late at night or on weekends. Since most users will request thecompressed files, and not review the DICOM data sets, it is notnecessary to send them immediately to the IDC.

Furthermore, the Internet data center includes, or is in communicationwith, a database server that is configured to index and search thearchive of DICOM data sets, which makes any compressed video file orDICOM data set available to a web-based client running web-browsersoftware. When a web-based client requests a video file from aparticular procedure, the IDC preferably detects the web-based client'sbandwidth. A multi-media server is then able to deliver theappropriately compressed image file as a streaming multi-media file tothe end user.

As the end user views the procedure video, the player preferablyprovides an option for stopping the image at a selected video frame.Once the viewer has been stopped, the reviewer can then select aparticular frame of interest using a keystroke or the mouse. Once thishappens, the player sends a message to a computer within the IDC withthe identification of the video being played and the frame of interest.The computer within the IDC then determines the lossless DICOM file thatcorresponds to the video being reviewed and determines the frame ofinterest within the lossless DICOM file. Once the frame of interestwithin the DICOM file has been identified, approximately 5-10 framesbefore and after the frame of interest are stored to a new losslessvideo file. These lossless video frames are then sent to the reviewer sothat approximately 10-20 frames of very clear, lossless images fromvideo procedure can be reviewed.

One efficient method for streaming media provides for an IDC server tocalculate the client's bandwidth and thereafter determine the number ofvideo frames to skip in order to show the full video procedure loopwithout having to wait for each successive frame to load. Conventionalvideo download systems will skip a fixed number of frames as the videois streamed to a player at the end user's computer. This allows thevideo image to begin playing, albeit roughly, almost immediately upon auser requesting to view the video. These systems, for example, will sendvideo frames 1, 10, 20, 30 . . . etc. until the end of the video isreached. These frames are stored on the end user's system and played asa jerky video. Conventional systems then send frames 2, 11, 21, 31 . . .etc to the end user. This video will be less jerky than the previousversion. This process continues until all of the frames have beendownloaded.

In one embodiment of the invention, video streams are ordered so thatthe frames are sent in sequential order However, the frames are orderedsuch that the video loop contains frames that are out of sequence incomparison to the originally captured video. For example, a video with10 frames can be ordered 1, 5, 10, 2, 6, 3, 7, 4, 8, 9. This would showthe video as jerky while only frames 1, 5 and 10 have been loaded, butwould become smoother as the additional frames in the file “fill in” theframe gaps. This is more efficient than prior systems because no framesare actually skipped as the frames are downloaded. Accordingly, theentire order of the frames within the video is reordered such that theserver may deliver the frames sequentially from the stored file withouthaving to skip a certain number of frames between each frame download.

In another embodiment of the invention, a hospital site serverautomatically sends each created DICOM video file, and the compressedversions of the video file to a computer at a Clinical ResearchOrganization that has permission to receive such file. This facilitatesthe sharing of lossless DICOM data without manual intervention requiredto download and save the data. Of course, the DICOM file couldalternatively be first transferred to the IDC, which then forwards thefile to the Clinical Research Organization. Using this embodiment aClinical Research Organization will have the requested files availablewhen they are ready to view them, without having to wait for a lossyDICOMDIR file to download. Additionally, a patient that is entered intoseveral clinical trials might have his cardiac data sent to multipleclinical research organizations.

In order to overcome the noted deficiencies in the prior art, aspects ofthe system described herein capture patient video data and combine itwith patient demographic information into a single patient data filethat is archived within a searchable database.

One aspect of the invention allows the patient data file to beimmediately accessed by other diagnosticians outside the immediatelaboratory.

Yet another aspect of the invention relates to automatically archivingand storing each patient data file for long-term storage and retrievalfrom a central database server.

Still another aspect of the invention allows remote access to anypatient data file from any device running web-browser software.

In another embodiment, a compressed patient video data file is storedwith varying compression ratios, or no compression at all, to archive aplurality of patient data files for later retrieval by devices withvarying bandwidths.

One other aspect of the invention provides multi-media streaming of thepatient data file over the Internet, wherein the compression ratio ofthe multi-media stream is dependent upon the user's calculatedbandwidth. In the future, as bandwidth speeds increase and costs comedown, no compression of the original image may be required.

Still another aspect of the invention is automatically delivery of thepatient video data file to a Clinical Research Organization, withoutthat organization being required to download the file from the Internet.

Yet another aspect of the invention is a video player that providespalindrome viewing capabilities. That is, the ability to play the videoimages in forward or reverse. Additional functionality of the playerallows the video to be paused, to loop certain frames, and to capturecompressed or lossless still images from the video images. Moreover, thesystem is provided with image enhancing features specifically designedfor medical images. For example, the video player includes tools for:zooming, edge enhancement, smoothing, sharpening, altering brightness,altering contrast, gamma correction, and other filters or enhancementsthat provide a better image to the reviewing physician.

A further aspect of the invention is a video player that allows thecompressed video images to be paused and then to retrieve thecorresponding lossless images for better diagnostic purposes.Furthermore, when a diagnostician clicks on an image frame of interest,the player grants immediate access to the lossless frame data, plusseveral lossless frames on either side of the frame of interest, forviewing lossless video data.

Additionally, a diagnostician can request a loop of lossless videoimages corresponding to a lossy video loop currently being viewed.

Yet another aspect of the invention is a server that is configured toautomatically retrieve the archived lossless video data from a centralIDC storage when a patient returns to the hospital so a doctor can haveimmediate access to the lossless data for reviewing.

Further objects of the invention will become apparent from the followingdrawings and description.

The above and other features of the invention including various noveldetails of construction and combinations of parts, and other advantages,will now be more particularly described with reference to theaccompanying drawings and pointed out in the claims. It will beunderstood that the particular method and device embodying the inventionare shown by way of illustration and not as a limitation of theinvention. The principles and features of this invention may be employedin various and numerous embodiments without departing from the scope ofthe invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram showing the components of one embodiment of avideo capture system.

FIG. 2 is a block diagram of a hospital acquisition station,illustrating an image capture system utilizing an analog camera, asystem for capturing images from a compact disk, and a system forcapturing images from a digital camera.

FIG. 3 is a block diagram of one embodiment of a hospital site server.

FIG. 4 is a block diagram illustrating one embodiment of an in-hospitalreview station.

FIG. 5 is a block diagram illustrating one embodiment of an InternetData Center.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The following detailed description discusses the invention utilized inconjunction with captured medical images.

A. Overview

In one embodiment inside a hospital, a medical image system makes use ofthree differing technologies: (1) The DICOM video standard, (2) Analogimage capture, and (3) High speed (Gigabit), local area networking.DICOM, an acronym for Digital Information and Communications inMedicine, is commonly used by a majority of medical imagingapplications. DICOM defines both an image file format as well as anetwork protocol, enabling imaging and acquisition products from avariety of vendors to interoperate. For a more complete discussion ofthe DICOM standard itself, please refer to the following resources:

Radiological Society of North America (RSNA)—A Non-TechnicalIntroduction to DICOM:http://www.rsna.org/REG/practiceres/dicom/nontechi-ntro.html NationalElectrical Manufacturers Association (NEMA)—The DICOM Standard:http://medical.nema.org/dicom.html

In embodiments of the system, cardiology images conforming to the DICOMstandard are taken directly from digital catheterization lab equipmentand stored on a Site Server within the hospital. The Site Server acts asa cache for local DICOM images captured over the most recent few weeksor months, and may be integrated with any vendor's catheterizationcamera equipment so long as the camera equipment conforms to the DICOMnetworking standard. Of course, it should be understood that DICOM isonly one standard for capturing and transmitting lossless image data.Embodiments of the invention are not limited to this one standard, andare anticipated to function similarly using differing video standards.

Images conforming to the DICOM standard are also preferably used by anIn-Hospital Review Computer Station to import and/or upload a DICOMcompliant CD (compact disc) to the Site Server, and to export selectedvideo studies from the system to a DICOM CD. Using video images in thismanner, the system can import, export and display cardiology imagesto/from any other vendor's equipment.

In order to acquire images from legacy film-based systems (withoutdigital DICOM capabilities), the system includes an Analog ImageAcquisition Station. Using real-time image capture technology, the ImageAcquisition Station converts the output of a catheterization cameradirectly to digital format, compresses the image using a JPEG losslessalgorithm, and finally converts the output to DICOM format. Starting andstopping of analog image acquisition is preferably controlled from afoot pedal attached to the catheterization lab system. The resultingDICOM images are sent to the Site Server in the same manner as a digitalDICOM acquisition. Using this technique, the system supports hospitalsites using a combination of digital and analog image capture withoutdifficulty. Frame rates up to 60 images per second are supported.

Finally, the Site Server, Review Station(s) and Image AcquisitionStation(s) are preferably connected together using a high-speed gigabitlocal area network (LAN). This gigabit LAN is 10 to 100 times fasterthan a normal Ethernet LAN, and provides near instantaneous access toany selected study and/or image from any Review Station. The gigabit LANis preferably a private segment, and thus it will not impact or impededata traffic across the existing in-hospital network.

1. Secure Archival Services

From the Site Server within the hospital, patient records and imagefiles are archived to an Internet Data Center (IDC) over the publicInternet This Internet link is preferably configured at T1 data rates(1.54 Mbps) or faster with an automatic archival process. Accordingly,no user intervention is required to “push” data from the hospital to theIDC.

Using Virtual Private Network (VPN) technology, the connection betweeneach hospital site and a central IDC is secure, safe and reliable.Commercially available VPN hardware and/or software is installed at eachhospital site, between the Site Server and the Internet interface,allowing only authorized communication to take place. The VPN ispreferably configured to require user-level authentication as well as ahigh level of data encryption, such as triple-DES (3DES). A highperformance VPN concentrator can be located at the IDC and configured tocommunicate only with authorized hospital sites.

The VPN concentrator will not allow access to the IDC from any otherlocation, or from any other user. Data transmitted between the hospitalsites and the IDC is encrypted using the highest level available(128-bit), such that it is unlikely to be intercepted, deciphered, orotherwise compromised. Encryption and decryption keys are preferablyrotated periodically and automatically.

2. Secure Web Access

Once archived at the IDC, patient data and cardiology images areavailable almost instantaneously from a web-browser based application.An authorized and authenticated user may login to a web server withinthe IDC and quickly browse studies of interest. In addition, compressedstreaming versions of cardiology image(s) are available using an AppleQuickTime.RTM. player. Of course, embodiments of the invention are notlimited to the Quicktime viewer. For example, other commercial or customviewers that support advanced image processing features are also withinthe scope of the invention. If the user has a broadband Internetconnection (DSL or greater speeds), the quality of the streaming imagesis remarkably similar to fill DICOM resolution.

Using various compression techniques, the lossless DICOM imagesoriginally captured from the catheter camera (either analog or digital)are converted to a compressed streaming file format automatically andtransparently to the user. There is minimal latency between the time auser clicks a desired image, and the streaming image begins to appear onthe screen.

Integration between the web-browser and the IDC is accomplished in thebackground using, for example, JAVA based programming technology incombination with Oracle Corporation's .delta.i enterprise levelrelational database product. It should be realized that other databaseproducts, such as the Microsoft SQL server could also be used withoutdeparting from the scope of the invention.

Secure web access is provided using a combination of digitalcertificates and Secure Sockets Layer (SSL) technology. First, a digitalcertificate is acquired from a leading industry source specializing inInternet Trust Services (e.g. Verisign, RSA, etc.) and is installed oneach authorized server computer. When accessing this server, the user'sweb browser will verify the digital certificate with the Trust Servicein order to make sure the user is communicating with the proper server.Once the server is authenticated, the user is asked to login to thesystem using a combination of account name, password and Site Id. Thus,both server and user authentication must take place prior to accessingany of the IDC data.

Finally, once both server and user are authenticated, all datatransmitted between the client (web browser) and the server is encryptedusing, as one example, 128-bit Secure Sockets Layer (SSL) technology.SSL is built into most modem web browsers, and provides transparentencryption and decryption of the data. This is the same level of dataencryption provided by the VPN (discussed above), but SSL is integratedinto the web browser providing ease of use.

3. Internet Data Center

The Internet Data Center (IDC) is the long-term repository for patientrecords, cardiology images, and compressed streaming images. Technologydeployed at the IDC has been selected for its ability to afford highavailability, reliability and its ability to scale to handle the amountof storage required. This technology includes such equipment as RAID(high speed and high capacity disk storage), Storage Area Network (SAN),robotic optical storage jukeboxes, and robotic tape back-up for disasterrecovery.

The IDC is designed with reliability and redundancy in mind and thusemploys multiple, redundant internal networks and servers such thatthere is no single point of failure. The IDC server computers areprotected by high performance network routers, firewalls and VPNconcentrators. This network equipment protects the BDC and its data fromunauthorized access and use, as well as from malicious intrusions. Thedatabase in the IDC is preferably powered by an Oracle database,providing a highly scalable enterprise relational database solution.

B. System

As discussed above, embodiments of the system relate to an image capturesystem for obtaining, storing and playing medical images. The medicalimages are preferably medical video images, but could also be staticdigital images in well-known formats such as GIF, JPG and TIFF. Themedical images are preferably captured as part of a cardiaccatheterization procedure, but can also include images captured fromother diagnostic imaging devices, such as CT, MRI, IVUS,ultrasonography, x-ray systems, and the like.

In reference to FIG. 1, a medical imaging system 100 and itssub-components are depicted. The sub-components will only be discussedgenerally in relation to FIG. 1, but will be given detailed treatment insubsequent figures and ensuing descriptions. As indicated, a hospitalsite 102 includes a plurality of imaging systems 105 a-c. Each of theimaging systems 105 a-c is linked to corresponding acquisition stations109 a-c. During a cardiac catheterization procedure, a technician, nurseor the physician inputs patient demographic data such as patient name,ID number, treatment required, etc. into a database housed on a computersystem linked to an acquisition station.

The data entered by the technician is then stored on the acquisitionstation 109 in order to identify the particular patient and procedureThe acquisition station 109 is preferably a Personal Computer type ofcomputer based on well-known microprocessors such as those manufacturedby Intel and Motorola. The acquisition station preferably runs aWindowsNT operating system although similar computer systems runningdifferent operating systems, such as Linux or UNIX, are anticipated tofunction similarly.

Dynamic video images from patients are captured through the diagnosticimaging system 105, such as those used in conventional cardiaccatheterization laboratories. A fall motion video of the catheterizationprocedure is captured using a camera at the imaging system 105 and theimages are preferably converted to DICOM images at the acquisitionstation 109.

Once a DICOM video of the cardiac catheterization procedure has beencaptured at the acquisition station, it is transferred, along withpatient identification data, over a 10 private high-speed network to ahospital site server 113. The DICOM video images are then temporarilystored on a storage 111 within a hospital site server 113. Once theimages have been stored at the site server 113, they are made availablefor viewing at a plurality of in-hospital review stations 117 a, b. Inone embodiment, the storage 111 is a conventional hard disk drive.

However, because the captured DICOM images are so large, the hospitalsite server 113 generates multiple compressed video streamscorresponding to each DICOM video. These video streams can be compressedwith well-known technologies, such as MPEG-4 and those provided by AppleQuicktime (Apple Corporation) or Microsoft AVI (Microsoft Corporation).Moreover, the compressed videos can be played by conventional AppleQuicktime or Microsoft AVI players available from the respectivecompanies. Other proprietary compression techniques are also within thescope of the invention.

Once the compressed video streams have been created at the hospital siteserver 113, they are transmitted to a database server 119 within anInternet Data Center (IDC) 121 through a high-speed telecommunicationsconnection. The IDC 121 stores the multiple streams of the compressedvideo data, along with the pertinent patient and procedure data in adatabase. Once the compressed streams are transmitted, the site server113 begins to transmit the large DICOM file to the IDC 121. However, thetransfer of the DICOM data is preferably at night, or when demand on thesystem is determined to be low, such as on a weekend. Thus, the largeDICOM images do not interfere with other data transport from a pluralityof hospitals to the IDC. In one embodiment the transfer of the DICOMfiles proceeds immediately as they are available. However they are givena lower priority than the smaller compressed files. The transferprotocol that sends the compressed files preferably supports multiplethreads or instances, thus allowing multiple compressed files to be sentto the IDC at the same time. However, in one embodiment, the system onlyprovides one thread for transferring the DICOM files. Accordingly, thelarger DICOM files queue up and transmit serially, one after anotherfrom the hospital site server to the IDC.

Once the compressed data streams have been transferred to the IDC 121,they are made immediately available for retrieval through a web server124 to a plurality of web-based clients 129 a-c running web-browsersoftware, such as Microsoft Internet Explorer or Netscape Navigator. Atypical web-based client 129 a, such as a computer, can request andretrieve a patient's compressed files, or lossless DICOM file fromeither the hospital site server 113, or the IDC 121. Long-term storageis available on the IDC, thus it is anticipated that most queries willbe made from the client computers to the IDC for file retrieval.

A computer running a web browser such as Internet Explorer or NetscapeNavigator receives web content from the web server 124 at the IDC 121.The web content either invokes a currently available commercial mediaplayer such as Apple Quicktime, RealNetworks RealPlayer or Windows MediaPlayer, or may contain an embedded scripted viewer, such as a Java-basedviewer programmed for displaying multi-media data streams.

Once the media player is active on the client computer, the multi-mediastream will begin playing from the multi-media server 128 at the IDC121. Thus, any authorized web-based client can access any patientstreaming image file from any device that has web-browser software. Thisallows collaborating diagnosticians to simultaneously view and sharepatient streaming image files without having to possess the data onphysical media.

Because the amount of data storage related to video images istremendous, a backup data system 130 is provided with a short-termstorage 135 and long term system 140 for storing the image data. Thesecomponents will be discussed in more detail with reference to thefollowing figures.

1. Acquisition Station

Referring to FIG. 2, the diagnostic imaging system 105 a is used tocapture patient video images. In this embodiment, the imaging system 105a is an analog imaging system that converts the captured analog datainto a digital format. Thus, the imaging system 105 a is linked to avideo capture card 201. In one embodiment, the video capture card 201 isa Matrox Genesis LC video frame capture card. While the A/D conversionis preferably performed by a hardware A/D converter on the video capturecard, a RAMDISK, or a portion of RAM set aside for exclusive use by anapplication which simulates hard disk behavior, can be optionallycreated to assist the hardware A/D conversion. The video capture card iscontrolled by a series of software libraries 202, such as the Matrox MILlibraries. More information on the Matrox video frame capture cards andcorresponding software can be found at http://www.matrox.com.

As the physician uses the imaging system 105 a, an on/off switch 209 inthe form of a foot pedal 209, sends a change-of-state signal to aninput/output board 213. The sensing of the change-of-state signal by theinput/output board 213 triggers a message to control software 214 tobegin or cease receiving and converting the video images. Afterreceiving an initial message from the input/output board 213, the AIDsubsystem begins acquiring images until another signal is received fromthe input/output board 213 to cease acquiring images.

Upon successful acquisition of patient video data, the acquisitionstation 109 combines the patient video data with the patient demographicinformation obtained from the lab technician into a valid data set.These steps may be repeated several times during a procedure, and at theconclusion of a procedure, the individual data sets are transferred tothe hospital site server 113.

It is preferable for the system to be able to acquire and process datafast enough to keep up in real time with the procedure being performed.One approach to this is utilizing a multi-buffering system, whereby aplurality of frames is moving through various stages of the systemsimultaneously. For example, as one frame is being acquired by thediagnostic imaging system 105 a, a second image is undergoing A/Dconversion, while yet another image is being inserted into a data file.This advantageously minimizes memory and allows continuous processing.

A second approach is to pre-allocate sufficient memory for the videocapture card to collect enough images to compile a complete data set.This method advantageously ensures that the images are collected andprocessed. In either case, the images are inserted into a data set,which is a lossless compilation of the acquired image frames. Thecreation of a valid data set may be performed by DICOM creator software217. In one embodiment, the DICOM creator software works in conjunctionwith a software toolkit 218 such as the LEADTOOLS Media Imaging Toolkit(LEAD Technologies, Inc., Charlotte, N.C.).

The DICOM Creator software 217 receives the digital patient video imagesas image pixel data and incorporates the patient demographic informationas appropriate DICOM data tags. The resultant combination is then savedas a valid data set. The acquisition station 109 then temporarily storesthe created data set as a DICOMDIR file in a local storage. In addition,the data set may be played through a DICOM Viewer 241, such as aJava-based DICOM viewing program. The DICOMDIR file is additionally sentautomatically to the hospital site server 113.

In addition to the method described above, archival image data can beloaded into the system. For example, a recordable optical compact disk,or CD-R 233 may contain previously recorded patient video data. Theacquisition station may contain a CD-ROM drive 229 and previouslycreated data sets may be acquired directly from the compact disk 233 andsent to the hospital site server 113.

Additionally, the compact disk 233 may contain digital data in a formatother than a DICOM data set, such as when the data were recorded by adiagnostic imaging device not connected to a DICOM compliant system. Inthis case, the digital data are read from the compact disk 233 andprocessed through the DICOM creator software 217, and then storedlocally 241 and on the hospital site server 113. Additionally, a newlyacquired DICOM data set may be saved to the recordable optical compactdisk 233 through the CD-R drive 229 installed into the acquisitionstation. Of course, the CD-R drive could be installed in other stations,such as the review station, hospital site server or other computerlinked to the system without departing from the scope of the invention.

It should be realized that image data may also be captured by a digitalimaging device, such as a digital camera (not shown). Because thepatient image data are already in digital format, the entire A/Dsubsystem can be bypassed. The digital patient data are processedthrough the DICOM creator software 217 and the resulting DICOM data setis then sent to the hospital site server 113.

2. Hospital Site Server

Reference is now made to FIG. 3, wherein the hospital site server 113 isdepicted. The hospital site server 113 receives captured video filesfrom the acquisition station 109 and archives them through an archivalservice 300 for retrieval from within the hospital. The archival service300 preferably provides the software necessary for processing incomingvideo images and storing them to disk. The archival service 300 providesbasic image acquisition, local storage and retrieval capabilities. Manyimage capture and processing systems, such as those compliant with theDICOM standard, are commercially available.

The captured video file is archived through an archival process 301 to afixed media 302. The video file is preferably retrievable through theinterface 303 to an SQL database component 305. The interface 303provides Remote Procedure Call (RPC) and Structured Query Language (SQL)access to the database 305, thus providing access to the video imagesstored in the image storage 302.

The in-hospital review station 117 is able to retrieve and view thelossless data sets over a high-speed private network from within thehospital. A diagnostician queries the database 305 for searchablecriteria such as patient name, patient ID, test date, and is able toretrieve and view the lossless video data set.

A diagnostician may also view the lossless data set from any deviceconnected to the hospital's high-speed network running web-browsersoftware. A device running web-browser software can access the storeddata sets by querying the SQL database just as the above-describedreview station 117. However, as described above, it is advantageous toprovide compressed video image files in addition to the lossless videofile.

Preferably, each lossless video file is converted using a mediaconversion module 315 to at least three different compressed videostreams, with each stream designed for delivery to an end user on theInternet at a different bandwidth. The compressed streaming versions aregenerated at the hospital on the site server to reduce the load on theservers at the Internet Data Center. Once the conversion module 315converts the lossless video into video files of varying compression,they are stored to the image storage 302.

Thus, end users at the hospital, such as physicians and technicians canmanually, or automatically, be presented with the lossless images, oralternatively, one of the compressed versions of the original losslessvideo data. The Java-based Web Objects 313 serve as the interfacebetween the hospital site server SQL database 320 and the applicationsrunning on the networked devices. The Java-based web objects embody thebusiness layer and incorporate all business logic in one place. Allsoftware applications requiring business rules invoke the web objects.This design allows modification of business rules or other algorithms inone place. Note that portions of the web-objects business rules areapplicable at both the Site Server and IDC, allowing a certain amount ofcode re-use. A networked device, such as the Review Station, can requesta patient data set from the storage 302, at which time the data set isdelivered through the server 113 to the requesting device. Thediagnostician has access to the lossless data set via the hospital'shigh-speed private network, such that retrieval time is minimal.

3. Hospital Review Station

FIG. 4 is a block diagram of the in-hospital review station 117. A userof the review station 409 initiates a stand-alone review station program401 designed with a graphical user interface to facilitate ease of use.Furthermore, the review station incorporates a video viewer program 405and toolkit 410, configured with VCR-like controls for forward, reverse,and pause capabilities. When a user invokes the review station program401, a set of java-based web objects 415 provide access to the SQLdatabase 305 located on the hospital site server 113. The requestedvideo data set is playable through the video viewer 405 at the reviewstation 117. The review station has the advantage of allowing adiagnostician to instantly view lossless data files over the hospital'shigh-speed network. The data are transferred through RPC, JDBC, orequivalent protocols, which minimize the data wait time. In an alternateembodiment, the review station viewer is a conventional Apple QuickTime,or similar video-viewing program, including a proprietary custom builtviewer, that is incorporated into Internet browser software.

4. Internet Data Center (IDC)

FIG. 5 is a block-diagram of the Internet data center 121, showing thevarious subsystems. As the hospital site server 113 delivers the patientvideo files to the IDC 121, they are automatically archived by thebackup data system 130. The backup data system comprises an archiveservice module 500 that is linked to a file server 501. The archiveservice module 500 provides the instructions for downloading andarchiving the lossless video file and video stream files from the siteserver 113.

The file server 501 is also preferably linked to a RAID image storage504 and optical or other near-line storage 505 facilities. The archivedpatient video files that were created as compilations of the separatevideo files from multiple procedures on a patient are searchable via theSQL database server 119 and the query results are displayed to the useras thumbnail images. As the patient video file is received at the IDC121, the thumbnail image that was taken from a median frame of the fileat the hospital site server is also saved as a thumbnail pointer to thatpatient video file. As a web-based client 129 requests a particularpatient data set by choosing a thumbnail image, the client's bandwidthis automatically detected and the optimally compressed DICOM data set isdelivered to that client.

However, a client can also request a file with less compression andbetter image quality. The content is delivered through the web server124 as is known in the art along with site specific web content 517. Thevideo data are delivered to the client as streaming media via themulti-media server 128.

In a preferred embodiment, the patient video file is automaticallyretrieved by the hospital site server 113. For example, when a patientreturns to see a physician, the lossless patient video file can beautomatically transferred from the backup data system 130 to temporarystorage on the hospital site server 113 for immediate retrieval by thephysician for review. This alleviates the wait time for a physician toaccess the file over the Internet once the temporary file is discardedfrom the hospital site server 113. It also allows the physician toadvantageously view the lossless data in place of the streamed lossyimage data.

Streaming techniques are known in the art and allow for a loop of videoto be retrieved and incrementally shown as each subsequent frame isdownloaded, until the fall loop is downloaded and viewed.

There are several methods for streaming. Most Internet content isdesigned to be played through once; hence a typical video loop isdownloaded sequentially and then played one time through. Note, howeverthat some video players will show streaming buffers frames as they aredownloading and do not wait until all frames have been downloaded. Theseplayers download a few frames to a buffer and play those frames as theremaining frames are continuously downloaded.

However, since most medical video loops are designed to by playedrepeatedly, other streaming techniques are advantageous. For example,embodiments of the invention will stream the first few frames of a videoprocedure while the system calculates the bandwidth of the link betweenthe player and streaming server. Once the bandwidth is determined, theplayer advantageously skips a certain number of frames such that thevideo loop is able to be shown without having to wait for every frame ofthe video to load. The system continues to download frames and skippinga determined amount of frames before downloading the next frame, and soon. The downloading and skipping process is preferably repeated and thevideo loop is shown more continuous with each subsequent pass. Thisallows for the video loop to begin display shortly after the clientrequests it. However, it should be realized that this embodimentproduces a very discontinuous video loop until all the frames aredownloaded and displayed in succession.

For example, assuming 100 frames are contained in a video loop, frames1-3 are first downloaded and displayed. During this initial download,the system calculates that 10 frames must be skipped in order to presentthe loop without waiting for the subsequent frame to download. Thesystem then serves frames 13, 23, 33, . . . 93. The server will thenrepeat the loop and display frames 1-3, read, store, and display frame4, display frame 13, read, store and display frame 14, display frame 23,and so on. The server continues the process until all frames aredownloaded and playing in succession.

Another embodiment of the invention provides another method forstreaming media to a player. In this embodiment, as the servercalculates the client's bandwidth and determines the number of frames toskip in order to show the full loop without having to wait for eachsuccessive frame to load, the individual frames are reordered to supportsequential downloading. For example, in the above example, rather thanskipping 10 frames between each frame downloaded, the entire collectionof frames is reordered such that the order of the video loop becomes1,10, . . . 100, 2, 11, . . . 91, 3, 12, . . . 92. This becomes moreefficient because the system does not have to skip frames between eachsuccessive frame download.

Thus, the entire order of the frames is reordered such that the servermay deliver the frames sequentially without having to skip a certainnumber of frames between each frame download. Additionally, the framesare stored into the client's local memory which reduces the timerequired to save and reload the data to/from a hard drive. For example,a typical image loop may require 50-100 MB of space. If the clientcomputer has 128 MB of memory, the entire image loop may be stored andplayed from memory, which considerably reduces the time required toreceive and play the entire loop. Finally, this described techniqueallows the server to deliver higher quality images with lowercompression and still achieve acceptable download times.

In another embodiment of the invention, the user at the hospital siteserver 113 is able to tag specific studies that should also be sharedwith other facilities. These facilities, for example a Clinical ResearchOrganization, will need the lossless data for their studies. Thehospital site server passes these tags along with the data to the IDC.The IDC includes a database table that indicates which tags belong towhich other sites. Instructions within the IDC then automatically routeeach DICOMDIR and accompanying ancillary patient data to a ClinicalResearch Organization that has permission to receive such file. Thisfacilitates the sharing of DICOM data without manual interventionrequired to download and save the data. Furthermore, a Clinical ResearchOrganization will have the requested files available when they are readyto view them. Additionally, a patient that is entered into severalclinical trials might have his cardiac data sent to multiple clinicalresearch organizations.

While the above description contains much specificity, these should beconstrued as illustrations and not limitations on the scope of theinvention. Additionally, there are numerous variations of the foregoingdescription not contained herein that do not depart from the scope ofthe invention as claimed. Accordingly, the scope of the invention islimited to the following claims.

1. A system for processing and distributing patient data, comprising:clinical research organizations performing different clinical trials; amedical services site that includes a server for receiving the patientimages of patients that are generated at the medical services site andstoring the patient images, a review station for retrieving patientimages from the server and displaying the patient images to adiagnostician, and a local network for transmitting the patient imagesbetween the review station and server, the patient images being taggedbased on participation by the patients in the clinical trials of theclinical research organizations; and an internet data center incommunication with the server and receiving the patient images and anytag information for the patient images that are transmitted by the siteover an internet communication network, the internet data centerincluding a database server storing the patient images, the internetdata center analyzing the tag information of the patient images andhaving the patient images with the tag information routed to theclinical research organizations identified by the tag information.
 2. Asystem as claimed in claim 1, wherein a user of the hospital server tagsthe patient data with the tag information based on participation of thepatients in the clinical trials being performed by the clinical researchorganizations.
 3. A system as claimed in claim 1, wherein the patientimages include lossless data sent to the clinical researchorganizations.
 4. A system as claimed in claim 1, wherein the serversends the patient images to the clinical research organizations.
 5. Asystem as claimed in claim 1, wherein the internet data center sends thepatient images to the clinical research organization.
 6. A system asclaimed in claim 1, wherein the server and/or the database server storeboth lossless patient images and images that have been compressed usinga lossy compression.
 7. A system as claimed in claim 1, wherein thepatient images are video images generated in a cardiac catheterizationlab by a catheterization camera.
 8. A system as claimed in claim 1,wherein the patient images are video images generated in acatheterization lab by an x-ray angioplasty machine.
 9. A system asclaimed in claim 1, wherein the internet data center compares the taginformation with a table identifying ownership of the tags with respectto the clinical research organizations and causes the routing of thepatient images among the clinical research organizations based on thetable.
 10. A method for displaying a compressed multi-media file andretrieving lossless frames of interest, comprising: displaying acompressed multi-media file in a viewer that has been compressed using alossy compression process; detecting when a selected frame of video inthe viewer has been selected by a diagnostician; retrieving a pluralityof lossless video frames immediately before and immediately after theselected frame, the lossless video frames having been stored withoutloss of resolution; storing the retrieved plurality of lossless videoframes in a new video file; and displaying the plurality of losslessvideo frames stored in the new file.
 11. The method of claim 10, whereinthe compressed multi-media file is an MPEG encoded file.
 12. The methodof claim 10, wherein the lossless video frames are retrieved from aDigital Imaging and Communications in medicine (DICOM) file.
 13. Themethod of claim 10, wherein the plurality of lossless video frames is 5to 10 video frames.
 14. A method for displaying a multi-media file to aclient computer comprising: calculating a client's effective bandwidth;determining how many frames of a multi-media file must be skipped inorder to render the entire file without waiting for a subsequent frameto download based on the calculated bandwidth; reordering frames of saidmulti-media file such that the file is downloaded sequentially; anddelivering the frames and repeatedly displaying said file whileinserting skipped frames as received by the client computer until allframes of the file are downloaded and displayed.
 15. The method of claim14, wherein the multi-media file is a video file.
 16. The method ofclaim 14, wherein the frames are reordered so that 5 to 10 frames ofvideo are skipped until the end of the multi-media file is reached. 17.The method of claim 14, wherein the frames are reordered so that theyare out of sequence in comparison to the originally captured videosequence.
 18. The method of claim 14, further including the followingsteps: displaying a compressed multi-media file in a viewer; detectingwhen a selected frame of video has been selected; retrieving a pluralityof uncompressed video frames immediately before and immediately afterthe selected frame; and displaying the plurality of uncompressed videoframes.
 19. The method of claim 18, including, after the retrievingstep, storing the retrieved plurality of uncompressed video frames in anew video file; and displaying the plurality of uncompressed videoframes stored in the new file.
 20. A method for processing patientdiagnostic images, comprising: collecting the patient diagnostic imagesat a medical services site; transporting the patient diagnostic imagesover a local network for the medical services site to a server systemfor the medical services site; storing the patient diagnostic images onthe server system; transporting the patient diagnostic images to areview station at the medical services site over the local network;displaying the patient diagnostic images on the review station for adiagnostician; transporting the patient diagnostic images to a datacenter in communication with the server system over an internetcommunication network; storing the patient diagnostic images at the datacenter that comprises a backup data system and at least one digitalcomputer configured as a multi-media server; and sending the patientdiagnostic images over the internet communication network when requestedat other medical services sites in response to a corresponding patientreturning to the medical services site.
 21. A method as claimed in claim19, wherein the step of collecting the patient diagnostic imagescomprises receiving the patient images from an x-ray angioplastymachine.
 22. A method as claimed in claim 20, wherein the step ofcollecting the patient diagnostic images comprises receiving the patientimages from a magnetic resonance imaging machine.
 23. A method asclaimed in claim 20, wherein the step of collecting the patientdiagnostic images comprises receiving the patient images from a computedtomography machine.
 24. A method for presenting patient video image datato a diagnostician, the method comprising: displaying the patient videoimage data, which have been compressed using a lossy compressionprocess, to the diagnostician in a viewer; enabling the diagnostician toselect frames of the patient video image data; retrieving losslesslystored video frames of the patient video data immediately before and/orimmediately after the selected frames and transmitting the video framesto the viewer; displaying the losslessly stored video frames for thediagnostician.
 25. The method of claim 24, wherein the step of enablingthe diagnostician to select the frames comprises enabling thediagnostician to stop the patient video data at a frame.
 26. The methodof claim 24, wherein the step of retrieving and transmitting videoframes comprises transmitting 5 to 10 frames of the patient video dataimmediately before and immediately after the selected frames.
 27. Amethod for processing and distributing patient video data, comprising:clinical research organizations performing different clinical trials;receiving the patient images of patients that are generated at a medicalservices site and storing the patient images, retrieving patient imagesand displaying the patient images to a diagnostician, tagging thepatient video images based on participation by the patients in clinicaltrials of clinical research organizations; and transporting the patientimages and any tag information to an internet data center; and theinternet data center analyzing the tag information of the patient imagesand having the patient images with the tag information routed to theclinical research organizations identified by the tag information.
 28. Amethod as claimed in claim 27, further comprising a user tagging thepatient data with the tag information based on participation of thepatients in the clinical trials being performed by the clinical researchorganizations.
 29. A method as claimed in claim 27, wherein a server atthe medical services site sends the patient images to the clinicalresearch organizations.
 30. A method as claimed in claim 27, wherein theinternet data center sends the patient images to the clinical researchorganization.
 31. A method as claimed in claim 27, wherein the patientimages are generated in a cardiac catheterization lab by acatheterization camera.
 32. A method as claimed in claim 27, wherein thepatient images are generated in a catheterization lab by an x-rayangioplasty machine.
 33. A method as claimed in claim 27, furthercomprising the internet data center comparing the tag information with atable identifying ownership of the tags with respect to the clinicalresearch organizations and causing the routing of the patient imagesamong the clinical research organizations based on the table.